Power Apps portals allow
the Power Platform to reach all the users your
business wants to connect to. However, to avoid
exposing any data, it is important to
understand portal security, which includes user
authentication and authorization. Users of Power Apps
portals are tracked in Microsoft Dataverse as contacts. The portal management
model-driven app provides access to
the contact table. It has forms to
manage passwords and view portal-specific
contact information. It also provides registration and profile
management forms for the portal. All interactions
and actions that a portal user
takes, for example, leaving a comment
on a page are tied to their contact row and
Microsoft Dataverse. Portal users can authenticate by using local or external
authentication. Let's take a closer
look at both methods. Basic authentication with
usernames and passwords are stored in the Microsoft Dataverse
contact row internally. By contrast, with
external authentication, credentials and
password management are handled by other
identity providers. Supported authentication
providers include OAuth2 for Microsoft, Twitter, Facebook, Google,
LinkedIn, and Yahoo, Open ID for Azure AD
and Azure AD B2C, as well as WS-Federation,
and SAML 2, which are used for
integration with on-premises AD and other
identity services. Portal administrators can
choose to enable or disable any combination of
authentication options through portal
authentication settings. Azure AD B2C is the recommended identity
provider for authentication. If support is required
from another provider, then it can be configured
in Azure AD B2C. After the user is authenticated and associated with a contact, Power Apps Portals use numerous tables to
define authorization. Authorization is what a
user is allowed to do. Selecting "Share" from the portal app
options will provide information on how to share the portal app with internal
and external users. Web roles allow an
administrator to control user access to portal content and
Microsoft Dataverse rows. A web role can be
associated with the following table rows:
website permissions, these define what
front side editing permissions a web role should
have if any are required. Web page access rules, these define what
pages are visible to a web role and what
actions can be taken. Lastly, table permissions, which define what
access a web role has to individual Microsoft
Dataverse tables. A portal contact
might be assigned to one or more web
roles at a time. Access rules and permissions of individual roles are combined to determine the resulting
permission set. One of the web roles in the
portal can be marked as anonymous and all the
others are authenticated. These roles allow you to
apply permissions and access rules to all portal users based on whether
they are signed in. If a user is not signed in, they will view the portal with the anonymous web
role permissions which should be the most
restrictive permissions. With Power Apps portals, you can empower anyone, whether they're from within or outside of your organization, to interact with
Microsoft Dataverse data. You now know more about
what portals are, as well as their
configuration themes and the fundamentals of
security and access. Why don't you give Power
Apps portals a go? You'll be sure to add
value to your business, from reducing call center costs to improving user satisfaction.